2. RPC：通过net/rpc方式连接

3. TCP：通过tcp方式连接

4. File：通过文件方式对接

5. Kafka：通过Kafka方式对接

6. Mock：用于测试，不写入tunnel，抛弃所有数据

消费者可以通过对接tunnel通道获取关注的数据，例如对接Direct通道直接写入目的MongoDB，或者对接RPC进行同步数据传输等。此外，用户还可以自己创建自己的API进行灵活接入。下面2张图给出了基本的架构和数据流。

MongoShake对接的源数据库支持单个mongod，replica set和sharding三种模式。目的数据库支持mongod和mongos。如果源端数据库为replica set，我们建议对接备库以减少主库的压力；如果为sharding模式，那么每个shard都将对接到MongoShake并进行并行抓取。对于目的库来说，可以对接多个mongos，不同的数据将会哈希后写入不同的mongos。

并行复制

MongoShake提供了并行复制的能力，复制的粒度选项（shard_key）可以为：id，collection或者auto，不同的文档或表可能进入不同的哈希队列并发执行。id表示按文档进行哈希；collection表示按表哈希；auto表示自动配置，如果有表存在唯一键，则退化为collection，否则则等价于id。

HA方案

MongoShake定期将同步上下文进行存储，存储对象可以为第三方API（注册中心）或者源库。目前的上下文内容为“已经成功同步的oplog时间戳”。在这种情况下，当服务切换或者重启后，通过对接该API或者数据库，新服务能够继续提供服务。

此外，MongoShake还提供了Hypervisor机制用于在服务挂掉的时候，将服务重新拉起。

过滤

提供黑名单和白名单机制选择性同步db和collection。

压缩

支持oplog在发送前进行压缩，目前支持的压缩格式有gzip, zlib, 或deflate。

Gid

一个数据库的数据可能会包含不同来源：自己产生的和从别处复制的数据。如果没有相应的措施，可能会导致数据的环形复制，比如A的数据复制到B，又被从B复制到A，导致服务产生风暴被打挂了。或者从B回写入A时因为唯一键约束写入失败。从而导致服务的不稳定。

在阿里云上的MongoDB版本中，我们提供了防止环形复制的功能。其主要原理是，通过修改MongoDB内核，在oplog中打入gid标识当前数据库信息，并在复制过程中通过op_command命令携带gid信息，那么每条数据都有来源信息。如果只需要当前数据库产生的数据，那么只抓取gid等于该数据库id的oplog即可。所以，在环形复制的场景下，MongoShake从A数据库抓取gid等于id_A（A的gid）的数据，从B数据库抓取gid等于id_B（B的gid）的数据即可解决这个问题。

说明：由于MongoDB内核gid部分的修改尚未开源，所以开源版本下此功能受限，但在阿里云MongoDB版本已支持。这也是为什么我们前面提到的“MongoDB集群间数据的镜像备份”在目前开源版本下功能受限的原因。

Checkpoint

MongShake采用了ACK机制确保oplog成功回放，如果失败将会引发重传，传输重传的过程类似于TCP的滑动窗口机制。这主要是为了保证应用层可靠性而设计的，比如解压缩失败等等。为了更好的进行说明，我们先来定义几个名词：

LSN（Log Sequence Number），表示已经传输的最新的oplog序号。

LSN_ACK（Acked Log Sequence Number），表示已经收到ack确认的最大LSN，即写入tunnel成功的LSN。

LSN_CKPT（Checkpoint Log Sequence Number），表示已经做了checkpoint的LSN，即已经持久化的LSN。

LSN、LSN_ACK和LSN_CKPT的值均来自于Oplog的时间戳ts字段，其中隐含约束是：LSN_CKPT